feat: support custom timeframes in each chart - #6

Ingesting the zellic snapshot as one transaction OOMed the 4GB server
(join hash table + transaction state exceeded DuckDB's 2.9GiB cap).
Ingest it in ~1M-row block-range slices instead, each its own
transaction, so the join builds against a slice rather than the whole
snapshot. The source is recorded in rollup_sources only after the last
slice; dedup makes re-running committed slices a no-op, so a crash
mid-snapshot resumes cleanly on the next start.

Also make zellic rollup failure non-fatal: serve parquet-era data and
retry on the next start instead of exiting.

Verified by a 2.5M-row snapshot test running under a 500MB DuckDB
memory limit.